Stage Verslag

Tom Vermeulen [email protected]

Dit verslag is tot stand gekomen in mijn 2^de leerjaar aan de Hogeschool Eindhoven, in het kader van mijn 1^ste stage. In dit verslag vindt u onderandere een beschrijving van het project IKS2-waardemeters.

Dit document geeft een beschrijving van het arbeidsproces met alles wat daarbij hoort. Voor een gedetailleerdere omschrijving van het programma en de werking er van verwijs ik graag naar dhr. J. Debal op afdeling warmwals van de Sidmar

Mijn dank gaat uit naar dhr. J. Debal, die mij tijdens de gele project duur heeft geholpen op het vlak van de informatica en dan vooral op het gebied van het programmeren in Visual Basic. Ook wil ik de P. de Jong bedanken die mij heeft begeleid bij het schrijven van de diverse stagedocumenten, waaronder ook dit stageverslag. Verder natuurlijk ook mijn vader en moeder die toch maar weer 10 weken met mij zaten opgescheept.

Tijdens mijn 1e stageperiode ben ik werkzaam geweest op de afdeling Warmwals van SIDMAR, waar ik werd begeleid door dhr. J. Debal, die op deze afdeling werkzaam is als IBO

Het project waar ik gedurende mijn stageperiode aan mag werken, bestaat in het automatiseren van de ingave, verwerking en rapportering van IKS2-waardemeeters. De toepassing hiervoor moet op het intranet kommen te staan.

In dit verslag vindt een gedetailleerde omschrijving van de Sidmar en het project. Een beschrijving van de huidige situatie inzake het process van de ingave, verwerking en rapportage van de IKS2-waardemeters. Verder zal er een beschrijving volgen van mijn werkzaamheden en de problemen die zich voordeden.

Als laatste zijn er nog een paar hoofdstukken met bijlagen zoals literatuurlijst, programmaschemas, programmalisting(op disk) en het PVA(b).

Voorafgaande op mijn stageperiode waren er een aantal onderdelen die afgewerkt moesten worden namelijk;

• Afspraak met de Bedrijfmentor over de stageopdracht.
• Afspraak met de Stagedocent over het PVA(s) / stageverslag.
• Plan Van Aanpak school (PVA(s)) voor stagedocent maken.

Alleen het eerste onderdeel van de drie kon door mij in de voorgeschreven tijd worden afgewerkt. Er werd in de planning van de stagevoorbereidin namelijk geen rekening mee gehouden dat, zowel de student en de stagedocent aan het eind van een blok het erg druk heb met tentamens en het afwerken van opdrachten. Om de hiervoor genoemde reden kon ik pas op mijn stageplaats echt goed contact opnemen met mijn stagedocent over het PVA(s) en het stageverslag. Het gevolg hiervan was dat ik het PVA(s) met een vertraging van enkele weken pas aan mijn stagedocent kon afleveren, de bureaucratische molen van het stagebureau was voor de versnelling van dit process ook niet echt bevorderlijk.

Ook bleek enkele weken na de aanvang van mij stage, dat mijn contract niet door school ondertekend kon worden vanwege een clouzule over ongevallen en het toebrengen van schade aan derden. Dit probleem kon worden opgelost als de Sidmar het contract aanpaste of de student een extra verzekering nam voor het stagelopen in het buitenland. Dit alles heeft ongeveer 6 weken geduurd. Van deze 6 weken heeft het contract er 5 bij het stagebureau doorgebracht.

Historiek.

In 1962 nam de Luxemburgse staalreus Arbed, samen met enkele andere Belgische en Europese staalbedrijven en financiële groepen het initiatief om aan het kanaal Gent-Terneuzen een staalbedrijf op te richten. De stad Gent verleende haar medewerking tot het verwerven van een terrein van 624 ha. De opbouw van Sidmar begon in december 1963 . Sidmar begon de activiteiten aan het kanaal Gent-Terneuzen in 1966 louter als koudwalserij. In 1967 startte de eigenlijke ijzer- en staalproductie met hoogoven, staalfabriek

en warmwalserij.

Situering

Het bedrijf ligt aan de rechteroever van het zeekanaal Gent-Terneuzen, op 15 km van het Gentse stadscentrum en op minder dan 17 km van de sluis van Terneuzen, waardoor het via de Westerschelde verbonden is met de Noordzee.

SIDMAR staat voor "Staal InDustrie MARitiem" waarmee expliciet aangeduid wordt dat het bedrijf zich op de scheepvaart richt voor het transporteren van de overzeese grondstoffen, hoofdzakelijk ijzerertsen en kolen.

Fig.1 plattegrond SIDMAR

Jaarlijks produceert Sidmar 3,6 miljoen ton ruwijzer en 4 miljoen ton ruwstaal. De jaarlijkse omzet bedraagt 50 miljard BEF. Sidmar stelt 5750 werknemers te werk en bestrijkt op dit ogenblik meer dan 1000 ha met een spoorwegnet van zowat 52 km en met ongeveer 24 kilometers banen.

Sidmar is een maritiem geïntegreerd staalbedrijf waarvan het productieprogramma uitsluitend gericht is op de fabricage van vlakke producten.

In de staalnijverheid is het gebruikelijk een onderscheid te maken tussen lange producten, zoals betonijzer, zware profielen, rails, e.a. en vlakke producten zoals rollen en platen. Sidmar produceert enkel vlakke producten met een hoge toegevoegde waarde en met als voornaamste kenmerken:

- uniforme mechanische eigenschappen

- zuiver oppervlak

- uitstekende vlakheid

- soepele vormbaarheid en rekbaarheid

- superieure lasbaarheid

Ruw geschetst komt het Sidmar-staal terecht bij:

Productieproces.

Het bedrijf beschikt over alle productie-eenheden om, vertrekkende van de grondstoffen het eindproduct (warmgewalste of koudgewalste platen en rollen) te produceren, nl.: - Kooksfabriek

Omdat steenkolen niet geschikt zijn om rechtstreeks in de hoogovens verbruikt te worden, worden de kolen verkookst. Ze bevatten immers te veel schadelijke of onnuttige producten voor het reducerend smeltproces en bovendien zijn ze niet sterk genoeg om de lading in de hoogovens te dragen. De kolen worden in de kooksovens opgewarmd. Daar er geen zuurstof aanwezig is in deze afgesloten ovens, verbranden de kolen niet. (= droge destilatie) Zodra de kolen verkookst zijn, worden zij geblust met water en laat men ze verder uitdampen op de kookskaai.

De verschillende soorten ertsen worden zorgvuldig gescheiden opgeslaan in de ertsopslagplaatsen. In nauwkeurig bepaalde verhoudingen worden ze opnieuw afgegraven en samen met smeltmiddelen en recuperatiestoffen vermengd op het

mengbed. Zo’n mengbed heeft tot doel de verschillende grondstoffen zo goed mogelijk met elkaar te vermengen. De gevormde bedden worden opnieuw afgegraven om een optimaal mengsel te bekomen.

Uit een mengsel van ijzererts, ijzerhoudende recuperatiestoffen en diverse smeltmiddelen produceren de sinterfabrieken een instant- ertsproduct van optimale stukgrootte en scheikundige samenstelling dat direct in de hoogovens gebruikt kan worden. Het te sinteren mengsel wordt samen met de fijn verdeelde kooks vermengd en gebakken. Daarna wordt de sinter gekoeld, gebroken en afgezeefd.

Hoogovens produceren vloeibaar ruwijzer door het reducerend smelten van ijzerertsen. Hiertoe wordt de hoogoven geladen met kooks, die verbrand worden, waardoor het reductiegas en de nodige warmte bekomen worden om de ertsen af te smelten. De smeltmiddelen, die zich in de sinter bevinden, hebben hoofdzakelijk tot doel het ruwijzer te zuiveren en het smeltpunt van de onzuivere elementen in de ertsen te verlagen. De hete lucht die ingeblazen wordt, moet ervoor zorgen dat heel het proces aan de gang blijft. Tijdens het hoogovenproces wordt er, naast ruwijzer, ook (ruwijzer-)slak gevormd. Deze slak bevat de smeltmiddelen en de onzuiverheden uit het erts en wordt samen

met het ruwijzer afgetapt.

In de staalfabriek wordt het ruwijzer, afkomstig van de hoogovens, omgezet tot staal door het verbranden van de onzuiverheden. Nadat het ruwijzer ontzwaveld is, wordt de zwavelslak ervan verwijderd. Na het afslakken worden afgewogen hoeveelheden schroot toegevoegd aan het ruwijzerbad. Daarna wordt zuivere zuurstof op het ruwijzer geblazen. Er wordt eveneens een hoeveelheid kalk en erts toegevoegd om het zuiveringsproces zo optimaal mogelijk te laten verlopen.

Wanneer de ongewenste stoffen in het ruwijzer ofwel tot slakken ofwel tot gassen verbrand zijn, voegt men toeslagstoffen en legeringselementen toe om de gewenste staalkwaliteit te bekomen. Het staal en de slak worden beiden afgegoten en om een nog betere kwaliteit te bekomen, kan het staal nog enkele behandelingen ondergaan.

• Kontinu-gieterij

• Voorwalsgroep

• Eindwalsgroep

• Warmbandafwerking

• Beitserijen

• Tandem

• TTS

• Stapelgloeierijen

• Continu- gloei- en afwerkingslijn

• Hardingswalserij

• Knipbanen

• Overwikkelbaan

WARMWALSERIJ

De slabs, afkomstig van de kontinu-gieterij worden afgevoerd naar het slabbenpark, waar ze aan de lucht of in waterbakken gekoeld worden.

Daarna worden ze doorgegeven aan de schoonbranderij waar ze nauwkeurig gecontroleerd worden op eventuele gietfouten. De foutieve plaatsen worden gemerkt en in de schoonbranderij weggebrand.

Vandaar worden ze overgebracht naar 1 van de 3 doorschuifovens of naar de hefbalkoven, waar ze op walstemperatuur gebracht worden. In de doorschuifovens duwt de laadmachine de slabs door de oven. Ze verlaten de oven via de ontlaadmachine, waardoor ze direct op de rollenbaan van de warmwalsgroep terechtkomen. In de hefbalkoven daarentegen rusten de slabs op watergekoelde balken. Voor het transport zorgen beweegbare watergekoelde hef-balken, die de slabs opnemen en ze stapsgewijze verplaatsen in de oven naar de uitgang toe.

De slabs zijn walsklaar als ze een temperatuur van ongeveer 1200 °C bereikt hebben.

Fig. 3 Doorschuifovens - Hefbalkoven

Elke slab die uit de oven komt, heeft een oxidelaag. Deze laag wordt door de oxidebreker verwijderd. Elke slab wordt aan boven- en onderzijde afgespoten met een waterstraal onder een druk van 140 bar.

De slabs worden met behulp van de rollenbaan naar de voorwalstuigen geleid. Het eerste walstuig is een omkeerwalstuig, dat de dikte van de slabs reduceert in 3, 5 of 7 walspassen. Gelijktijdig vindt een breedtebeheersing plaats in 3 stuikpassen. In het tweede walstuig gebeurt slechts één enkele gladpas.

De slabs verlaten de voorwalstuigen als dikke plaat.

Fig. 4 Voorwalsgroep

Voor de eindwalsgroep bevindt zich een draaiende schaar die de kop en de staart van de dikke plaat afknipt.

De oxidelaag van de dikke plaat wordt verwijderd door de oxidebreker.

De dikke plaat gaat vervolgen het eerste eindwalstuig binnen. Elk walstuig van de eindwalsgroep reduceert de dikte van de plaat naar een vooropgestelde einddikte, variërend tussen 1,5 en 12,7 mm. Daartoe wordt in elk walstuig de walsdruk heel nauwkeurig afgeregeld.

De dikke platen verlaten de eindwalstuigen als banden.

Fig. 5 Eindwalsgroep

De banden worden met waterstralen onder lage druk gekoeld tot de juiste opwikkel-temperatuur bereikt is. Daarna worden ze opgewikkeld op 1 van de 3 haspels tot rollen. De opgewikkelde rol wordt dan van de haspel genomen, gekanteld d.m.v. een kipstoel en op een transportketting geplaatst. Daarop wordt de rol afgevoerd naar de warmbandafwerking. In de warmbandafwerking wordt het warmgewalste staal, dat als rol verkocht wordt, klant-klaar gemaakt, verpakt en verzonden. Indien het staal als plaat verkocht wordt, dan wordt de rol in de warmbandafwerking op breedte en lengte geknipt tot platen. Deze worden op hun beurt gevlakt, gecon- troleerd op eventuele fouten, gestapeld, verpakt en verzonden.

Fig. 6 Warmbandafwerking

Het project waaraan ik tijdens mijn stage ga werken is: het automatiseren van de ingave, verwerking en raportage van waardeparameters. Deze parameters werden gebruikt bij het bepalen van de performantie van de afdeling. Samen met de gegevens van de andere produkte afdelingen ontstaat zo een goed beeld over de prestaties van de onderlinge afdelingen in kader van het IKS2-project (Interne Kwaliteitszorg Sidmar).

Deze waardeparameters komen van alle verschillende sekties binnen de Warnwals en betreffen bjivoorbeeld veiligheid,…. De verantwoordelijke personen voor deze cijfers gaven ze op papier aan de Heer Debal die ze dan invoerde in een spreadsheet. Vervolgens werden hiervan een aantal grafieken en lijsten aan het verantwoordelijke de leiding en het afdelingshoofd.

De Software

Als eerste zal de database worden aangemaakt moeten worden dit zal gebeuren met Microsoft Acces 97. Vervolgens zullen met Microsoft Visual Basic 5.0 Enterprise Edition de AciveX objects gemaakt worden. Als laatste moeten de Web-paginas gemaakt worden, dit zal hoofdzakkelijk gebeuren met Microsoft Frontpage 97. Het testen zal over het algemeen naast elkaar gebeuren dat wil zeggen

Internet Explorer om de client kant te simuleren, VisualBasic om de ActiveX objecten te debuggen bij ongewenste resultaten op de intra-net paginas. Daarnaast wordt Acces gebruikt om de queries aantepassen.

De intranet-server, Microsoft's Internet Information Server 3.0 is al operationeel, het aanpassen/veranderen van de instellingen van de server is niet nodig en behoort ook niet tot het project.

De Werking

De bedoeling van het project is dat de ingave, verwerking en raportage via het intranet van de afdeling gaan. Hiervoor is het nodig dat de waardeparmeters in een database komen te staan welk via DAO door in Visual Basic gemaakte ActiveX objecten aangesproken kunnen worden die op hun beurt weer door het ISAPI Filter kunnen worden aangesproken door middel van de COM interfase. De ISAPI communiceert op zijn beurt met de Server via CGI. En als laatste communiceert met de CLIENT via HTTP.

HTTP = Hyper Text Transfer Protocol

CGI = Common Gate Way Interface

ISAPI = Inter Server Application Program Interface

COM = Common Object Modelling

DAO = Data Acces Object

De Specificaties

Internet Explorer

De methode van aanpak van het project was aan de hand van prototyping. Dit houdt in dat de normale project weg die gevolgde wordt bij het ontwerpen van software namelijk; definieren, coderen en testen, niet opgaat het is namelijk een continu proces waarbij na het testen weer defineren, coderen en testen volgt. Het grote voordeel hiervan is dat er veel sneller getest kan worden en de verandering die gemaakt moeten worden aan het eind van de test minder ingrijpen zullen zijn. Een bij komend voordeel is dat het programma als het ware "evolueert" tot een goedsamenhangend geheel. Een nadeel is wel dat van een zeer gedetailleerde planning voor het ontwikkelprocess geen plaats is aangezien er veel eerder in het project al dusdanige aanpassing gemaakt zullen worden dat de planning simpel weg niet meer aantehouden is.

Voor het project zijn eerst twee databases gedefinieerd, een voor het inloggen en een voor de applicatie. Beide databases zijn in Acces gedefineerd. De ene database bevat de IKS2-gegevens die eerst in Excel-werkboek waren aangemaakt. De andere database, Login bevat de gegevens over de gebruikers zoals onderandere welk deel van de applicatie zij wel of niet mogen gebruiken. Deze database is zo opgezet dat hij "gerecyckeld" kan worden bij andere toepassingen. Een nadeel hiervan is dat we alles nu al vast leggen en daar in de toekomst rekening mee moeten houden. Een voordeel is dat het ontwikkeltijd spaart bij een volgend project.

Login Database

De Login database met de releties en de attributen

Zoals in de afbeelding van de Login database te zien is

hebben we tbMembership en tblPermissions toegevoegd

om te voorkomen dat er veel-op-veel relaties voor komen

hebben we de database dus genormaliseerd.

Ook is nu goed te zien dat de we gekozen hebben om de

gebruikers per groep rechten te geven en niet per persoon

dit vanwege het feit dat dit makkelijker is in het gebruik. Als er nu bijvoorbeeld een applicatie toegevoegd moet worden dan hoeft dit niet honderd keer voor honderd gebruikers appart zijn permissies te veranderen. Maar hoeft dit maar een keer voor de gehele groep te gebeuren.

Ook bevat de database een hele groot aantal queries zoals die hiernaast zijn weergegeven. De vier standaard hoofdqueries zijn alle vier aanwezig:

• delete queries
• insert queries
• update queries
• select queries

Ook is te zien dat bij de delte querries voor een delete van Members of Permissions er meerdere mogelijkheden zijn. Dit is gedaan om de mogelijkheid op tehouden een user of een group uit een de membership tabel te verwijderen met allen de user of group-id als selectie criteria.

Ook is te zien dat er drie vershillende soorten select zijn voor de Membership tabel. Zo is er de mogelijkheid om bij de selectie van een membership een group, een user of beide als selectie criteria op tegeven.

IKS2 Database

Ook de IKS2-database is net als de Login-database genormaliseerd, zodat er geen veel-op-veel releaties voorkomen.

Net als bij Login zijn de vierstandaard queris aanwezig. Zo is er qdelCategorie welke een categorie verwijderd aan de hand van diens ID. Ook is er een speciale querrie namelijk qmkCategorie. Deze Categorie maakt een tabel Categorie aan.

Voor een uitgebreider overzicht van de databases verwijs ik naar de bijlagen

Standaard naamgeving van queries

De naamgeving van queries is samengesteld uit een prefix en een fuctionele naam. De functionele naam bevat tevens de tabelnaam beginnend met een hoofdletter. De prefix is vastgelegd in functie van de actie en wordt steeds in kleine letters weergegeven. De standaard naamgeving is afkomstig van de Microsoft Technet CD. Bij het programmeren in Visual Basic zullen we ook daar de standaard naamgeving handhaven. Het positieve gevolg van het streng aanhouden van deze standaard naamgeving is dat de leesbaarheid van de code vergroot wordt.

De applicatie bestaat uit twee onderdelen namelijk het Login gedeelte en het IKS2 gedeelte. Alvorens de gebruiker een onderdeel van de applicatie kan gebruiken zal hij moeten inloggen op de Warmwals site. Vervolgens wordt dan bepaalt welk applicaties hij wel en niet mag gebruiken. De programmas worden in Visual Basic geschreven. De programmas gebruiken de database-bestanden Login en IKS2 voor hun gegevens bewerkingen. De programmas worden als ActiveX objecten

aangemaakt.

Login

Het programma Login bevat allen ActiveX klassen. Deze klassen hebben alle functionaliteit om de eisen die aan Login worden gesteld inzich. Ook is de klasse classTools toegevoegd deze is nodig om de speciale functionaliteit die WebAction biedt aan te kunnen spreken.

clsLogin is de eerste klasse die aangesproken wordt bij het inloggen. Hij checkt of de UserID en het Password kloppen met wat in de Login database staat. Als alles klopt wordt clsApp aangeroepen anders wordt een foutmeleding gegenereerd.

In clsApp wordt met database Login gekeken welke applicaties de gebruiker mag gebruiken. De klasse Environment is een klasse die enkel geebruikt wordt bij het testen, hij bevat een functie die een boel gegevens van het operatingsystem en het netwerk bekend maakt. De klassen NotGranted, Granted en Revoked zijn alleen beschikbaar voor de administrator en geeft de gegevens over de verschillende gebruikers inzake de toegangsrechten. Tot slot is er de clsNewUser welke gebruikt wordt om een nieuwe gebruiker toe toevoegen.

HTML-object is een klasse die gebaseerd is op de HTML reference voor Microsoft Internet Explorer 3.0.

Voor elke tag uit de HTML-reference is er een klasse met de naam van die tag. Die klassen hebben op hun beurt weer voor elke attributes een let en een get property zodat er van gelezen en naar geschreven kan worden. Verder bevat elke klasse een functie Special. Deze functie Special genereert de HTML code die bij zo'n tag hoort.

De bedoeling van deze klasse was dat met het aanroepen van een paar functies met uit deze klasse je heel simpel een redelijk goede dynamische internetpagina zou kunnen genereren.

Door tijd gebrek hebben deze klasse jammer genoeg niet in gebruik kunnen nemen. In toekomstige projecten zal deze klasse waarschijnlijk wel gebruikt worden, het geen tot grote tijdspesparingen kan leiden.

IKS2 en IKS2Acces

Het programma IKS2 bevat alle functionaliteit die getoond gaat worden aan de gebruiker. Zo is er de klasse clsReportShowGraph welk laat de taak heeft de html-code te genereren om de grafiek met de geselecteerde waardemeter weertegeven in de browser. In IKS2 worden dus de HTML –codes voor de bepaalde paginas gegenereed. Tevens verwerkt IKS2 de inkomende variablen van de WebAction. Hij genereert een foutmelding als de variabelen niet voldoen aan de gestelde eisen bijvoorbeeld het maximum wordt overschreden.

bijvoorbeeld een verandering aan de tabel User moet worden gemaakt dan zal in IKS2 de aanroep clsUSER.Update(parameters) in IKS2Acces klasse clsUser en procedure Update aanroepen welke vervolgens met de overgedragen parameters de gevraagde update in de database zal aanbrengen. Dit gebeurt door dat de parameters weer doorgegeven worden aan de vooraf gedefineerde querry qupdUser. Voor een uitgebreidere beschrijving van de processen verwijs ik naar de programma diagrammen en de source code.

Standaard naamgeving in Visual Basic

De naamgeving van van klassen, forms, modules en andere objecten die in forms gebruikt worden in Visual Basic net als bij de queries in Acces samengesteld uit een prefix en een fuctionele naam. De functionele naam bevat tevens de klassenaam beginnend met een hoofdletter. De prefix is vastgelegd in functie van de soort klasse en wordt steeds in kleine letters weergegeven. De standaard naamgeving is afkomstig van de Microsoft Technet CD. Net als bij de het aanhouden van deze naamgeving in Acces zal het erin Visual Basic voor zorgen dat de gemaakte code leesbaarder wordt. Voor meer prefixes als in het hier bovenstaande tabelletje verwijs ik naar de Technet CD’s of naar de documentatie die over dit onderwerp in het bezit is van ondergetekende.

Na het programmeren van de verschillende programmas en objecten moest er worden getest. Aangezien we met ActiveX objecten wekten konden we de test applicaties gewoon in Visual Basic schrijven en moesten we niet gelijk met HTML gaan testen.

Debuggen

Login hebben we tegelijk met IKS2getest als een soort schaduw applictie die niet via het intranet werkt maar local als gewone windows applicatie. Hiernaast is een diagram te zien van alle forms die we nodig hebben om Login en IKS2Acces te Testen.

Het testen van IKS2 gedeelte gebeurt op de zelfde manier. Twee windows met Visual Basic, een met IKS2AccesTest en de andere met IKS2Acces. Ook hier wordt IKS2AccesTest als laatste gerund. Het verdere process is het zelfd als bij Login.

ErrorTrapping

Bij het testen is er intensief gebruik gemaakt van "Error Trapping" en Loggen. We hebben hiervoor een ActiveX object gebruikt dat AppLogger heet. Deze AppLogger maakt circulaire bestanden aan dat wil zeggen als het bestand vol is begint hij weer aan het begin met schrijven. Voorelke klasse hebben wij een eigen log-bestand gemaakt. Elke keer als een klasse wordt aangroepen worden in het bijbehorende log bestand de volgende dingen weggeschreven:

-Tijd + Class Initialize

-Tijd + Class Terminate

-Einde van het Loggen

in een log-bestand ziet dat er bijvoorbeeld als volgt uit:

Om nu de errors te "Trappen" is er in elke procedure van elke klasse een statement toegevoegd. Treed er nu een fout op dan springt het programma naar dit statement en wordt de error samen met de tijd weggeschreven naar het log-bestand van die klasse. Dat ziet er dan als volgt uit:

Deze error houdt in dat de een element waar een bewerking op gedaan moet worden niet voorkomt in de database.

Het statement voor dat we gebruikt hebben voor deze "Error Trapping" ziet er als volgt uit:

Als er een error voorkomt in de klasse wordt er naar ErrorTrap gesprongen deze schrijf dan de erro weg en vervolgens wordt er teruggesprongen naar Exit_Function.

Bij het testen van IKS2Acces en Login is dit "Error Trappen" nog niet erg belangrijk omdat we met Visual Basic twee of meerdere objecten tegelijk kunnen debuggen. Bij het debuggen van IKS2 aan de had van testruns van de intranet applicatie is dit wel heel handig aangezien we dan niet met twee runnende objecten kunnen werken maar alleen met de gecompileerde en aangemaakte versie.

Nadat het testen van Login en IKS2Acces, moest de intranet applicatie geschreven worden. Eerst moest er een Login pagina gemaakt worden waarop geregistreerde users konden inloggen. Ook moest er een mogelijkheid zijn voor nieuwe users om zich aan te melden. De paginas die hiervoor gemaakt moesten worden zijn met Microsoft Frontpage aangemaakt. Dit is alleen met deze paginas mogelijk en niet met de volgende omdat de verder applicatie werkt met dynamische internet paginas. Deze paginas worden aangemaakt door IKS2 en zijn daarom niet met Frontpage aan te maken.

Login

Deze pagina zit vrij simpel in elkaar, hij bevat namelijk een HTML-form met twee HTML-input boxen. In die twee input boxen moet de user zijn userid en password ingeven. Voor een schema van de parameter overdracht verwijs ik naar bijlage C. Klopt alles dan wordt hij door gestuurd naar de applicatie pagina waarop hij de voor hem toegangkelijke applicaties tezien krijgt. Voor een schematisch programma overzicht verwijs ik naar Bijlage D. Als er iets niet klopt wordt de foutpagina getoond met daarop de bijbehorende fout. Was alleen het password verkeerd dan wordt er automatisch teruggekeer naar de Login pagina. Was ook de userID fout dan wordt door gegaan naar de Newuser pagina. Op deze pagina kan de onbekende gebruiker zich aanmelden. Ook op deze pagina wordt met een form gewerkt, het verschil met de andere pagina is dat er nu een HTML-input boxen zijn.

IKS2 waardemeters

De IKS2 intranet applicatie die wij geschreven hebben is opgesplitst in drie onderdelen namelijk:

• IKS2 Rapportering waardemeters
• IKS2 Ingave waardemeters
• IKS2 Management waardemeters

Het eerste deel van de applicatie namelijk rapportering waardermeters is voor ieder die inlogt toegankelijk zijn de ander twee onderdelen van de applicatie moeten echter alleen toegankelijk zijn voor de mensen die de IKS2 waardemeters invoeren en veranderen. Dit wordt bereikt door dat inde IKS2 database ook is aangegeven welke gebruikers wat mogen. Als er nu een gebruiker inlogt dan zullen alleen de hyperlinks naar die delen van de applicatie verschijnen waar tot hij toegang dient te hebben.

Management is het gedeelte van de toepassing dat eigenlijk door het minst aantal personen bebruikt zal worden. De taak van deze toepassing ligt in het toevoegen van nieuwe, verwijderen van en veranderen van de gegevens over waardemeters, de parameters. Dit deel van de toepassing laad bij het activeren alle verschillende parameters in een listbox, zodat de gebruiker die parameter kan kiezen die hij wil veranderen of verwijderen. Ook kan de gebruiker ervoor kiezen om een nieuwe parameter in tebrengen. Als de gebruiker ervoor kiest de gekozen parameter te verwijderen dan wordt alvoorens de parameter wordt verwijdert eerst alle gegevens van die parameter nog een keer getoond op een pagina en er wordt om een bevestiging gevraagd. Kiest de gebruiker dan voor verwijderen dan wordt de parameter uit de database verwijdert, is dit gelukt dan zal er door IKS2 een HTML-pagina met een bevestigende tekst worden gegenereerd. Is het niet gelukt dan zal IKS2 aangeven welke error er is opgetreden. Vervolgens wordt weer terug gekeerd naar de start pagina van management waardemeters.

Als de gebruiker kiest voor het veranderen van de gekozen parameter dan zal de IKS2 een pagina genereren met alle gegevens van die parameter maar nu in inputboxes en listboxes met de verschillende hoofdwaarden (verandwoordelijke, sektie en categorie), zodat de gebruiker de waarden kan veranderen. Heeft de gebruiker de waarden van de parameter verandert en gekozen om de verandering door tevoeren dan zal IKS2 de veranderingen doorvoeren en een HTML-pagina genereren die aangeeft of alle parameters klopten en of de verandering zijn door gevoerd. De applicatie keert terug naar het begin van management.

De laatste functie die dit deel van de applicatie heeft is het toevoegen van een nieuwe parameter. De gebruiker krijgt nu weer voor alle verschillende waarden van parameters inputboxes en listboxes te zien, maar deze zijn leeg zodat hij er een totaal nieuwe parameter kan invoeren. Als de gebruiker besloten heeft de parameter toetevoegen dan zal IKS2 die opdracht uitvoeren en een HTML-pagina genereren die aangeeft of het gelukt Is en zo ja wat de ID is van de nieuwe parameter.

Dit deel van de applicatie is, zoals de naam ervan al suggereerd voor het ingeven van waardemeters. Bij het start van dit deel van de applicatie zal IKS2 een lijst genereren met alle verantwoordelijke, de sekties, de categorieen en het jaartal. De gebruiker selecteerd dan een gebruiker, vervolgens zal IKS2 met de gegeven waarden een lijstje samenstellen van alle waardemeters die er voor de geselecteerde waarden in dat gegeven jaar zijn. De waarden worden weergegeven per maand in een inputbox. Zo kan de gebruiker reeds bestaande waarden veranderen en nog niet bestaande waarden ingeven. De andere gegevens over de waardemeter kan de gebruiker niet veranderen en zijn dus gewoon weergegeven. Als de gebruiker de veranderingen/nieuwe ingaven wil doorvoeren zal IKS2 de gegevens voor hem checken, dat wil zeggen er wordt gekeken of de ingegeven waarden tussen de minimum en maximum waarde van deze waardemeter ligt is dat niet het geval dan zal er een HTML-pagina gegenereerd worden welk dit aangeeft. Klopt alles verder dan zal IKS2 per maand de ingegeven waarden in de database inbrengen. Er zal een HTML-pagina gegenereerd worden die aangeeft welke maand met succes zijn ingevoerd. Vervlogens keert de applicatie automatisch terug naar de startpagina van dit deel van de applicatie

Rapportering waardemeters is dat gedeelte van de applicatie die ervoor zorgt dat er een goede, duidelijk en eenduidige weergave van de waardemeters plaatsvindt. De gebruiker kan zeggen welke waardemeter hij van welk jaar veergegeven wil zien. IKS2 zal alle maandwaarden van de gekozen waardemeter voor dat jaar uit de database ophalen en dan bet behulp van het activeX control Olectra Chart een mooie weergave maken in de vorm van een staafdiagram. Hoewel we eerst van plan waren dit met de activeX control ieChart te doen, bleek deze niet genoeg capaciteiten te bezitten, bovendien zou de Olectra Chart eenvoudiger in het gebruik zijn. Dit laatste bleek echter achteraf tegen te vallen.

Testen

Deze test procedure bij de intranet applicatie is totaal anders als bij de testprogrammas. Het debuggen zou volgens de handleiding van WebAction kunnen gebeuren met een in Visual Basic runnened ActiveX object, dus zeg maar real-time. Bij onze versie van WebAction werkte deze functie echter niet. Het gevolg hiervan was dat elke keer als er zich een error voor deed, Internet Explorer een foutmelding gaf waar we niets mee konden doen. Door dit probleem waren we gedwongen de ErrorTrapping, zoals die beschreven staat in het Hoofdstuk Testen toepassen. Ook waren we genoodzaakt elke keer als we veranderingen hadden aangebracht opnieuw een full compile te doen en het programma laten aanmaken. Een bij komend nadeel aan deze onhandige debug methode was dat elke keer als we een nieuwe build lieten uitvoeren we vooraf dat bewuste programma moesten uit zetten, ook wel bevrijden genoemd. Hiervoor had WebAction gelukkig een handige link bij het programma meegestuurd, deze link stelde ons instaat de objeceten snel en gemakkelijk te bevrijden.

LOGIN

Query: qdelUser

IKS2